
Addendum 



A SCHEME FOR DETERMINING TRANSPORT LEVEL INFORMATION IN THE 
PRESENCE OF IP SECURITY ENCRYPTION 





730 . 37334X00 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



Inventors : 
Invention : 



Rajeev KOODLI and Senthil SENGODAN 

SCHEME FOR DETERMINING TRANSPORT LEVEL 
INFORMATION IN THE PRESENCE OF IP SECURITY 
ENCRYPTION 



Antonelli, Terry, Stout & Kraus 
Suite 1800 

1300 North 17th Street 
Arlington, VA 2 2209 



SPECIFICATION 

To All Whom It May Concern: 
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5 BACKGROUND OF THE INVENTION 

The present invention relates to a method and 
apparatus for permitting access to information contained in 
selected fields of a packet subjected to security processing, 
particularly by intermediate nodes between source and 

10 destination nodes when the packet is transmitted on a packet 

switched network from the source node to the destination node. 

In packet switched networks, packets are transmitted 
between nodes connected to the network to effect communication 
between the nodes. Information in the packets may include 

15 messages and commands such as a request for service, connection 
management controls, or data. The packets transmitted on the 
packet switched network are transmitted according to, for 
example, the Internet Protocol (IP) which defines how to format 
various information in the packets for transmitting on the 

20 packet switched network. Currently, the IP is defined 

according to IPv4 where the "v4 11 indicates version 4 of the 
Internet Protocol, and IPv6 where the w v6" indicates version 6 
of the Internet Protocol . 

Security across the packet switched network is 

25 afforded by IP Security Protocol (IPsec) as set forth in 

"Security Architecture for the Internet Protocol", by S. Kent 
et al, Request for Comments (RFC) 2401, Networking Group, 
Internet Engineering Task Force (IETF), November 1998. IPsec 





is a protocol designed to provide various security services for 
traffic at the IP layer and upper layer protocols in both the 
IPv4 and IPv6 environments. 

These security services are implemented through the 
5 use of two traffic security protocols, namely, Authentication 
Header (AH) Protocol, and Encapsulating Security Payload (ESP) 
Protocol and through the use of Cryptographic Key Management 
Procedures and Protocols. The set of IPsec Protocols employed 
in any context, and the ways in which they are employed, are 
10 determined by the security and system requirements of users, 

i § 

applications and/or sites/organizations. 
Zj The AH protocol provides security services of 

g=f connection list integrity, data origin authentication and anti- 

F-JJ 

yj replay. The ESP protocol provides security services of 

Ll 15 confidentiality (encryption) , and limited traffic flow 

flj confidentiality. The ESP protocol can also provide security 

,jj services of connection list integrity, data origin 

authentication and anti-replay. These protocols may be applied 
alone or in combination with each other to provide a desired 
20 set of security services in IPv4 and IPv6. When either of these 
protocols are used, particularly security processings are 
performed. Each protocol supports two modes of use: Transport 
Mode and Tunnel Mode. In the Transport Mode the protocols 
provide protection primarily for upper layer protocols. In the 
25 Tunnel Mode the protocols are applied to tunneled IP packets. 

Both AH and ESP make use of Security Associations 
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(SAs) . An SA is a simplex "connection" that affords security 
services to the traffic carried by it. An SA is uniquely 
identified by a triple including a destination IP address, a 
Security Protocol (AH or ESP) , and a Security Parameter Index 
5 (SPI) . The endpoints of an SA can, for example, be a pair of 

hosts, a pair of security gateways or a security gateway and a 
host. The security gateway can, for example, be a router, a 
firewall, etc. When either end or both ends of an SA are a 
security gateways then the tunnel mode is used. 

10 Prior to the use of the above described security 

protocols, an SA must be established. Thus, for example, prior 
to use of the ESP protocol between, for example, two hosts, an 
SA, identified according to the triple described above, must be 
established between the pair. When the ESP protocol is used, 

15 the entire IP packet, with the exception of the IP header, the 
AH protocol header if present and the ESP header, is encrypted 
during packet transmission as illustrated by the shaded areas 

in Fig. 1. 

i 

As illustrated in Fig. 1, the IP packet which has 
2 0 been subjected to security processings according to the ESP 
protocol includes an IP header 102, an ESP header 104, a 
transport PDU (Payload Data Unit) 106, an ESP trailer 108 and 
an ESP authent icator 110. The ESP header 104 includes an SPI 
field 104-1 and a sequence number field 104-2. The transport 
2 5 PDU 106 includes payload data which can be of variable length, 
and the ESP trailer 108 includes a padding field 108-1, a 
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padding length field 108-2 and a next header identifier field 
108-2. The payload data can include, for example, transport 
level information including Transmission Control Protocol (TCP) 
Header, User Datagram Protocol (UDP) Header or Internet Control 
5 Message Protocol (ICMP) Header and port number. The sequence 
number contained in the sequence number field 104-2 of the ESP 
header is a 32 -bit monotonically increasing number that is 
present to prevent replay attacks. Since the payload data 106 
and the ESP trailer 108 are encrypted according to the security 
10 processing effected by, for example, the ESP protocol the only 

7: information visible to any intermediate nodes between the 

source and destination of the SA (including the first-hop- 

21 ingress-egress routers) would be the IP header 102, the ESP 

Vj header 104 and the ESP authenticator 110. 

^ 15 Although not illustrated, an IP packet subjected to 

=21 security processings according to the AH protocol in addition 

% to ESP, when used, causes the same problems as when the ESP 

1J 

protocol above is used. Namely, the entire transport payload 
including the transport headers is encrypted. Therefore, an IP 

20 packet subjected to security processings according to the AH 
and ESP protocol would have a configuration similar to that 
illustrated in Fig. 1 with the exception that the AH header 
would be present as well. 

The security processing, particularly encryption, of 

25 selected information in selected fields especially the 

transport level information including the transport protocol 
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and the port number, is undesirable for certain intermediate 

nodes such as, for example, packet classifier/marker nodes 

providing differentiated services, policing nodes such as 

firewalls, or management nodes for metering. For example, if 

5 the ingress router also serves the function as a packet 

classifier/marker node providing differentiated services, this 

router will not be able to access the transport level 

information, such as transport protocol and port number that 

may used as indicators for indicating the type of service 

10 desired according to the differentiated services framework. 

O For example, a TCP destination port number of 80 may indicate 

. 

4* access to a webserver, which could be used to classify and mark 

H the Differentiated Services Code Point (DSCP) in the packet for 

an appropriate treatment for web related services. This type 
f 15 of classification and marking known as multi-field 
j-j* classification (and marking) and differentiated services 

(DIFFserv) would not be possible if ESP is used as described 
above . 

Therefore, there is a need to provide selected field 
20 accessibility for certain intermediate nodes in the presence 
of, for example, security processing of an IP packet without 
compromising the security of the system nor requiring 
modifications to the existing protocols. 



25 
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SUMMARY OF THE INVENTION 

The present invention provides a method and apparatus 
for permitting access to selected information in selected 
fields of a packet, which has been subjected to security 
5 processing, by intermediate nodes in a packet switched network 
when the packet is being transmitted on the packet switched 
network . 

Particularly, the present invention provides a method 
and apparatus which permits access to selected information such 

10 as transport level information, normally included in a payload 
of a packet upon which encrypting security processing has been 
performed according to a security protocol by a node in a 
packet switched network during transmission of the packet. 

The present invention accomplishes the above by prior 

15 to performing security processing according to an encrypting 
security protocol on a packet, storing information related to 
selected information normally included in a payload of the 
packet in a header of the packet. The field in the header that 
this information is placed is not subjected to the encrypting 

20 security processing. Thereafter, the security processing is 
performed on the packet . The packet including the header 
having stored therein information corresponding to the selected 
information normally included in the payload and the payload 
upon which security processing has been performed is then 

2 5 transmitted on the packet switched network to its destination. 

Therefore, according to the present invention, by 
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storing information related to the selected information 
normally included in the payload of the packet in the header of 
the packet as well, access to the selected information by 
intermediate nodes between the source and destination nodes in 
5 a packet switched network is possible. The information related 
to the selected information normally included in the payload of 
a packet can, for example, be representative of the selected 
information or the selected information itself. The 
information related to the selected information can be freely 

10 accessed by the intermediate nodes, decoded if necessary, and 

used to initiate specified processings on the packet by the 
' intermediate node. 

The present invention is particularly applicable to 
I the security services provided by the IP Security (Ipsec) 

15 Protocol, wherein the Encapsulating Security Payload (ESP) 

protocol is used. Implementing ESP on an IP packet requires 
that portions of the IP packet, particularly the payload of the 
IP packet, which includes transport level information such as 
transport protocol and port number, be encrypted during 

20 transmission. Encrypting portions of the IP packet, 

particularly the payload of the IP packet eliminates access by 
intermediate nodes to the transport level information contained 
in the encrypted portions of the IP packet when the IP packet 
is transmitted between source and destination nodes on a packet 

25 switched network. 

The present invention allows for access of the 
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transport level information contained in the encrypted portions 
of the IP packet during transmission of the IP packet by- 
storing information related to the transport level information 
in the security protocol header of the IP packet. The 
5 information selected to the transport level information could, 
for example, be stored in the sequence number field of the 
security protocol header of the IP packet. Intermediate nodes 
in the packet switched network can easily access such 
information since it is part of the security protocol header 
10 which is not encrypted according to security processings 

effected on the IP packet according to the encrypting security 
protocol . 

BRIEF DESCRIPTION OF THE DRAWINGS 
15 The present invention will be more apparent from the 

following detailed description, when taken in conjunction with 

the accompanying drawings, in which: 

Fig. 1 is a schematic diagram illustrating the 

configuration of an IP packet when the ESP protocol is used; 
20 Figs. 2a-c are schematic diagrams illustrating 

different scenarios for Security Associations; 

Fig. 3 is a schematic diagram illustrating the 

sequence number field of the IP packet when the ESP protocol is 

used according the present invention; 
25 Figs. 4a and b are tables illustrating the values of 

various bits of the sequence number field of an IP packet 
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configured according to the present invention; and 

Figs. 5a-c are schematic diagrams illustrating 
various modes of operation relative to the ESP protocol 
according the present invention. 

5 

DETAILED DESCRIPTION OF THE INVENTION 

The present invention will be described relative to 
Figs. 1, 2a-c, 3, 4a-b, and 5a-c. It should noted that the 
present invention is not limited to the embodiments illustrated 
10 in these figures and other embodiments recognizable by those of 
J3 ordinary skill in the art are encompassed within the scope of 

si the present invention. 

O The present invention is intended to operate in a 

yj packet switched network where security services according to 

jM: 15 IPsec ESP are provided. These security services effected by 
ft] security processings performed according to the ESP protocol of 

jl the IPsec is initiated once a Security Association (SA) has 

been established. A SA is a simplex "connection" that affords 
security services to the traffic carried by it. A SA is 
20 uniquely identified by a triple including a destination IP 
address, security protocol (AH or ESP) , and a Security 
Parameter Index (SPI) . The endpoints of a SA can, for example, 
be a pair of hosts, a pair of security gateways or a security 
gateway and a host. The security gateway can, for example, be 
25 a router, a firewall, etc. 

Figs. 2a-c illustrate examples of scenarios for the 



establishment of SAs . Each figure illustrates an SA including 
two sources, source 1 (SI), 201 and source 2 (S2) , 203, one 
destination 205 and 3 SAs 207. Each SA 207 of each figure 
terminates at the same destination 205. 
5 As illustrated in Fig. 2a, the SAs established 

between SI 201 and the destination 205 and S2 203 and the 
destination 205 are all identical as per the solid line arrows. 
Particularly, between SI 201 and destination 205 two identical 
SAs 207-A are established and between S2 203 and destination 
10 205 a single SA 207-A identical, as per the solid line arrow, 
to the SAs established between SI 201 and destination 205 is 
established . 

Fig. 2b illustrates a case where the two SAs 207-A 
established between SI 201 and destination 205 are identical as 

15 per the solid line arrows. An SA 207-B established between S2 
203 and destination 205 is different as per the dashed line 
arrow, from the SAs 207-A established between the SI 201 and 
the destination 205 . 

Fig. 2c illustrates a case where all SAs established 

20 between the sources SI 201 and S2 203 and the destination 205 
are different from each other. Namely, between SI 2 01 and the 
destination 205 an SA 207-A is established as per the solid 
line arrow and a different SA 207-C is established as per the 
dotted line arrow. Further, between the S2 203 and the 

25 destination 205, a SA 207-B different from the SA 207-A and SA 
207-C, as per the dashed line arrow is established. 
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As per Figs. 2a-c, the choice of identifying an SA 
lies with the receiver (destination) . Since the SA is uniquely 
identified by the triple destination IP address, security 
protocol and SPI, the destination is required to consider 
5 certain issues while determining whether a SA is unique or 

distinct. For example, when the security protocol (AH, ESP) is 
different, then the SA established between the source and 
destination is different. However, two SAs that terminate at 
the same destination and use different security protocols can, 
10 for example, use identical SPIs. Further, two SAs that 
43 terminate at the same destination and which use the same 

S J security protocol may be either identical or distinct. In this 

lUsr 

O situation, the SA would be identical if the respective SPI 

*W values are identical. Otherwise, the SAs in this situation 

^ 15 would be different. A destination must use different SAs if 

the security processing namely, encryption algorithm, key 
4? links, key value, etc., is different. If the security 

processing is identical then the destination may use identical 
SAs. However, the destination may use different values for the 
20 SA if it so desires. 

In the conventional technique, once an SA has been 
established and security processings according to the ESP 
protocol (and optionally AH) has been initiated, the IP packet 
being transmitted on the packet switched network is entirely 
25 encrypted with the exception of portions or all of the IP 

header and the security protocol (AH or ESP) header. Such a 
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packet is illustrated, for example, in Fig. 1 relative to the 
ESP protocol. As shown in Fig. 1, the transport PDU 106 and 
the ESP trailer 108 are fully encrypted whereas the IP header 
102, the ESP header 104 and the ESP authenticator 110 are not 
5 encrypted. The encrypted areas are shown by the shading. 

The conventional technique as described above, 
suffers from numerous disadvantages one of which being that 
selected information in selected fields of the IP packet are 
encrypted, thereby causing such information to be inaccessible 
10 to intermediate nodes which may use such selected information 
f J3 to transmit or perform other processings on the packet. This 

'"""4 now inaccessible information could, for example, be transport 

O level information which is used by the intermediate nodes to 

W provide, for example, differentiated services, policing or 

J;" 15 metering. The transport level information includes, for 
pJ example, transport protocol information including TCP, UDP and 

ICMP and port number information. The transport level 
information is normally carried in the payload data portion of 
an IP packet. The inaccessibility of such information normally 
2 0 carried in the payload portion of an IP packet does not permit 
the intermediate nodes between the source and destination nodes 
in a packet switched network to perform such value added 
services relative to the communication. 

The present invention overcomes the above by 
25 permitting access to selected information normally included in 
the payload of a packet upon which encrypting security 
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processing has being performed. Such is accomplished in the 
present invention by, for example, placing information related 
to the selected information in the security protocol header of 
the IP packet. This operation is conducted prior to security 
5 processing being performed on the packet according to the 

security protocol being used. The information related to the 
selected information could, for example, be representative of 
the selected information or the selected information itself. 
The selected information could, for example, be transport level 
10 information including transport protocol and port number 
•JJ information. The information related to the selected 

SJ information stored in the security protocol header is stored 

O along with information identifying the security protocol. 

U After the above described storing operation, security 

Ml 5 processing is performed on the packet and the packet is 
i1j transmitted to its destination on the packet switched network. 

fe J3 Since information related to the selected information is now 

contained in the security protocol header of the packet which 
is not encrypted, such information is readily accessible by 
2 0 intermediate nodes in the packet switched network existing 
between source and destination nodes. 

According to the present invention, the sequence 
number field of the security protocol header can be used to 
convey information related to the selected information when 
2 5 security processing has been performed and the packet is being 
transmitted. Other fields of the security protocol header or 
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the IP header could possible be used. The present invention is 
not limited to use of the sequence number field. The present 
invention provides a modified security protocol header 
specifically modifying the sequence number field 104-2. The 
5 sequence number field 104-2 is modified to include information 
related to the selected information normally contained in the 
encrypted payload portion of the packet when security 
processing has been performed. The sequence number field 104-2 
of the security protocol header, particularly the ESP header 
10 illustrated in Fig. 1, is 32 bits long and can be configured 
Jk such as that illustrated in Fig. 3. 

sj As illustrated in Fig. 3, the leading 8 bits of the 

p sequence number field 104-2 could be used to provide 

uj 

yj information related to the transport level information of the 

1**15 packet with the remaining 24 bits being used, for example, to 
fy provide information regarding the sequence number. While the 

■dj specific number of bits of the sequence number field assigned 

to be used to provide information related to the transport 
level information may vary, it is important that knowledge of 
2 0 the scheme used be provided to each of the intermediate nodes 
of an established SA. 

Specifically, an intermediate node that requires 
access to such information related to the transport level 
information needs to be aware of the mechanism employed by the 
2 5 source node of the SA to represent such information in the 

sequence number field of the security processing header of the 
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packet. Several mechanisms are possible by which an 
intermediate node may be informed of the specific number and 
uses of the leading bits of the sequence number field to 
represent the transport level information. These mechanisms 
5 can include, for example, standardizing the number and usage of 
the bits so that any intermediate node need merely to refer to 
predetermined (protocol) standard interpretations. Also the 
source node of the SA may indicate the number and usage of 
these bits to an intermediate node by communications which can 
10 be performed on or off line. The present invention as 
J5 illustrated, for example, in Fig. 3 provides a particular 

sis 

s,l mechanism. However, the present invention is not limited to 

p such a mechanism. 

Ly In Fig. 3, a Transport Level ID (TLID) 401 is 

L^15 provided. The TLID 401 includes a plurality of leading bits of 

fy the sequence number field 104-2. The TLID 401 includes a 

Transport Protocol ID (TPID) 403 and a Port Number ID (PNID) 
405. The TPID 403 and the PNID 405 are each formed by a 
plurality of bits, the total of which are equal to the bits 
20 used for the TLID 401. In the present invention as illustrated 
in Fig. 4, the TPID 403 comprises two bits (a, b) and the PNID 
405 comprises six bits (c-h) . 

The TPID 403 identifies the particular transport 
protocol (TCP, UDP, ICMP, etc.) used and the PNID identifies the 
2 5 associated port number. It should be noted that the exact 

number of bits used for the each of the TPID 403 and PNID 405 
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can be different from that illustrated in Fig. 3. The present 
invention is not limited to the embodiment described above. 

The present invention provides a Transport ID Mapping 
Table 500 as illustrated in Fig. 4a providing information 
indicating corresponding relations between the TPID 403 and the 
transport protocol 501. In the table, the TPID 403, including 
bits a and b, identifies the particular transport protocol 501 
which forms part of the transport level information. The 
transport protocol 501 could, for example, include ICMP 501-1 
corresponding to TPID bits w 00" 403-1, UDP 501-2 corresponding 
to TPID bits "01" 403-2, TCP 501-3 corresponding to TPID bits 
"10" 403-3 and undefined 501-4 corresponding to TPID bits "11" 
403-4 . 

The present invention also provides a Port Number ID 
mapping table 502 as illustrated in Fig. 4b providing 
information indicating corresponding relations between the PNID 
4 05 and port numbers. In the table, the PNID 405 can be used to 
identify either a source port number 503, a destination port 
number 504 or both. A flag A 506 is provided to indicate 
whether a particular bit sequence of the PNID 4 05 has been 
assigned to a flow of packets (A=l) or not to any flow of 
packets (A=0) . 

The tables illustrated in Figs. 5 a and b can be 
provided, for example, by the source node of the SA to the 
intermediate nodes existing between the source node of the SA 
and the destination node of the SA. Any of the mechanisms 



described above for accomplishing this can also be used. These 
tables are stored in the intermediate nodes for use in decoding 
the information conveyed by the leading bits of the sequence 
number field of the security protocol header of an IP packet. 
5 The mapping of the values illustrated as being contained in 

these tables, as provided to any one of the intermediate nodes, 
is performed, for example, by the source node of a SA. 

The mapping of the values of the tables illustrated 
in Figs. 4a and b can, for example, be unique for a triple 
10 including a source IP address, a destination IP address and an 
■41 SPI . Inclusion of the source IP address in this triple permits 

%J the creation of a mapping locally within the source of an SA 

C3 without the need for consulting other sources that may share 

hi the SA. It should be noted that SPI in the above noted triple 

HIS corresponds to the SPI in, for example, the ESP header but not 
I1J to the SPI in, for example, the AH header. The SPI of the AH 

%Q header may also be present in the same IP packet. In other 

words, the security protocol field is implicit in the triple 
with a constant value of ESP. When a new six bit value needs 
2 0 to be assigned to a new flow of packets, the source of the SA 
may utilize any available value between 0 and 63. 

Since the mapping is unique to a triple including a 
source IP address, a destination IP address and an SPI, the 
session/flow is uniquely identified by a triple including the 
25 source IP address, the destination IP address, the SPI and the 
PNID. Here the PNID refers to a portion of the leading bits of 
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the sequence number field of a packet configured according to 
the present invention. 

It is possible that if the same SA is used for 
several simultaneous sessions between the same source and 
5 destination pair, the Port Number ID mapping table 502 could be 
exhausted, for example, after 64 UDP or 64 TCP sessions. In 
such a case, there would not be any free PNIDs that the source 
node could allocate to a new session. In order to alleviate 
this problem, the destination node of the SA could assist by 
10 changing the SA when the number of simultaneous TCP (or UDP) 
^4 sessions from the same source node that require identical ESP 

Zj processing equals 64. Note that this is an implementation issue 

« and does not violate the IPsec protocol. It should be noted 

yl that the larger the number of bits that are used for this 

yi5 purpose, the faster the SA refresh is required to be performed 
fjj for the particular SA. 

J3 Once the source node of the SA has performed the 

mapping, it must notify intermediate nodes that need transport 
level information of such mapped values. Specifically, 

20 information organized in a manner similar to the tables 

illustrated in Figs. 4a and b are provided to the intermediate 
nodes. The network points that need to be aware of such a 
mapped values include, for example: (1) a diff-serv marker node 
(2) a management metering node, or (3) a policy enforcement 

25 node (firewall) . For a diff-serv marker node, the only node 
that needs to be notified is the node that is responsible for 
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marking the packets that originate from the source node. For a 
policy enforcement node or firewall, it is likely that all 
firewalls that need to police the traffic need to be informed 
of the mapped values. Similarly, for a management metering 
5 node, all nodes that are interested in metering the traffic 

need to be aware of the mapped values. The specific mechanisms 
that the source node of the SA employs to deliver the mapped 
values to intermediate nodes can be of any type as described 
above including those that may become known to one skilled in 
10 the art. 

-jj Figs. 5a-c are schematic diagrams illustrating 

Si various modes of operation relative to the ESP protocol 

£3 according to the present invention. The diagrams illustrated 

kj in Figs. 5a-c are provided as examples of how the present 

M=15 invention operates in a packet switched system. Although the 

In I 

fy ESP protocol alone is used in the schematic diagrams 

J3 illustrated in Figs. 5a-C, other security protocols used along 

with ESP, particularly the AH protocol used with ESP would 
operate in a similar manner. 
20 Fig. 5a illustrates a configuration where the ESP 

protocol is operated in the transport mode, and where source 1 
(SI) 601 and source 2 (S2) 602 and destination (d) are sources 
and destinations of various SAs . Further, gateway (Gl) 607 is 
an egress router and gateway (G2) 609 is an ingress router. 
25 First, a case will be considered where two UDP sessions are in 
existence between SI 601 and D 605, and one TCP session is in 
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existence between S2 602 and D 605. In this case, it is 
assumed that the ESP protocol with the same algorithms, keys 
and other security parameters is desired for each of the three 
sessions. Since the number of simultaneous sessions using the 
5 same transport protocol (TCP/UDP) and requiring identical ESP 
protocol security processing (encryption algorithm, keys etc.) 
that originates at any single host and terminates at D 605 does 
not exceed 64, D may use the same SA for each of these 
sessions. The common SA for each of these three sessions is 
10 identified by the triple <D's IP address, ESP, SPI>, where SPI 
4s is a specific value for the SPI. In this establishment of SAs 

%| using the Internet Key Exchange (IKE) , there does not exist a 

O mechanism whereby the transport protocol (TCP/UDP) information 

hi is conveyed to the destination of the SA at the time of SA 

MQ.5 establishment. This then implies that one of two things may be 
nJ done : 

42 (1) Using the existing IKE mechanisms, the destination D 

6 05 may use a common SA for a maximum of 64 simultaneous 
sessions originating from the same source (and terminating at D 

20 605) which require identical ESP protocol security processing. 
This is independent of whether these sessions are UDP or TCP. 

(2) The existing IKE mechanisms may be extended so that 
the destination D 605 is aware of the transport protocol of the 
session at the time of SA establishment. In such a case, the 

25 destination D 605 may use a common SA for a maximum of 64 

simultaneous sessions originating from the same source (and 
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terminating at D 605) which require identical ESP protocol 
security processing and which also use the same transport 
protocol (TCP/UDP) . 

Now assume that, for each of the three sessions, 
5 transport level information needs to be sent to the egress 

router Gl 607 for marking purposes and the ingress router G2 
607 for policing/metering purposes. Source SI 601 assigns an 
available TLID to each of the UDP sessions, where the leading 
two bits of the TLID are set to "01" (indicating UDP) . 
10 Similarly, source S2 602 assigns an available TLID to the TCP 
session terminating at D 605 such that the leading two bits of 
the TLID are set to "10" (indicating TCP) . These sessions are 
O identified by the triple < (source) IP address, D's IP address, 

yj SPI, TLID>. Since the destination D 605 has ensured that not 

ML 5 more than 64 simultaneous sessions (TCP & UDP combined with 
fij existing IKE; TCP or UDP with modified IKE) with the same ESP 

u3 protocol security processing share the same SA, it is 

guaranteed that a TLID will be available at the source for 
assignment . 

20 Fig. 5b illustrates a configuration where the ESP 

protocol is operated in the usage tunnel mode. In Fig. 5b, SI 
601 and S2 602 are session sources and D 605 is the common 
destination. The sessions (from SI 601 and S2 602) pass 
through firewalls Fl 611 and F2 613, as well as through Gl 607 

25 and G2 609. An SA exists between Fl 611 and F2 613 while Gl 
607 and G2 609 (intermediate nodes) need transport level 



21 



information for each of the sessions between SI 601 or S2 602 
and D 605 for the purpose of packet marking or management 
metering . 

First, a case is considered where two UDP sessions 
5 exist between SI 601 and D 605, and a TCP session exists 
between S2 602 and D 605. Packets from each of the three 
sessions flow through Fl 611, Gl 607, G2 609 and F2 613 before 
going on to D 605. Packets belonging to each of the three 
session are afforded the same ESP protocol security processing. 
10 In other words, the same ESP protocol security processing for 
the SA between established Fl 611 and F2 613 is used for 
Hi packets belonging to each of the three sessions, 

p The SA between Fl 611 and F2 613 is uniquely 

y] identified by the triple <F2's IP address, ESP, SPI>. The 

ML 5 conditions for the destination F2 613 of the SA to change the 
fij SA for identical ESP protocol security processings are as 

di follows: 

(1) Using the existing IKE mechanisms, the 
destination F2 613 of the SA may use a common SA for a maximum 

2 0 of 64 simultaneous sessions originating from Fl 611 (and 

terminating at F2 613) which require identical ESP protocol 
security processing. This is independent of whether these 
sessions are UDP or TCP sessions and is also independent of the 
source (such as SI 601 and S2 602) that these sessions 

25 originate from. 

(2) The existing IKE mechanisms may be extended so 



22 



that the destination F2 613 of the SA is aware of the transport 
protocol of the session at the time of SA establishment. In 
such a case, the destination F2 613 may use a common SA for a 
maximum of 64 simultaneous sessions originating from the same 
5 Fl 611 (and terminating at F2 613) which require identical ESP 
protocol security processings and which also use the same 
transport protocol (TCP/UDP) . 

(3) The existing IKE mechanisms may be further 
extended so that the destination F2 613 of the SA is aware of 
10 the session source (SI 601 or S2 602) at the time of SA 

sjj establishment. In such a case, the destination F2 613 may use 

4= 

Si a common SA for a maximum of 64 simultaneous sessions 

O originating from the same Fl 611 (and terminating at F2 613) 

pi 

yj which require identical ESP protocol security processing, which 

M_5 use the same transport protocol (TCP/UDP) and which originate 
nj at the same source. This is used only when the session source 

Jj is also needed by the intermediate node. Since the session 

source IP address is encrypted in the tunnel mode of the ESP 
protocol, and an intermediate node desires this information, 
2 0 then such information needs to be suitable mapped within the 
sequence number field or by other means. 

After information related to the transport level 
information is stored in the sequence number field of the ESP 
protocol header, Fl 611, then conveys the mapping tables to the 
25 intermediate nodes Gl 607 and G2 609 that requires such 
transport level information to permit decoding of such 
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information . 

Fig. 5c illustrates a case involving a nested SA 
scenario. As seen in Fig. 5c , an end-to-end transport -mode ESP 
protocol SA exists between the session source (SI 601 or S2 
5 602) and the session destination (D 605) . In addition, this SA 
is nested within a tunnel mode ESP protocol SA existing between 
Fl 611 and F2 613. In this case, destination D 605 determines 
whether a new SA should be created for sessions requiring 
identical ESP protocol security processing based on the 

10 conditions discussed for the case illustrated in Fig. 5a. In 

S3 

jj this case, however, the session sources pass on the mapping 

tables to the source of a first security gateway existing in Fl 
p 611, and not to the intermediate nodes (Gl 607 and G2 609) that 

hj require transport level information. In addition, the mapping 

yL5 tables are passed on to any other intermediate nodes (such as 
nj G3 615) that are present beyond the termination of the nested 

,J3 SA. F2 613 determines whether a new SA needs to be created 

between Fl 611 and F2 613 based on the conditions discussed in 
the case illustrated in Fig. 5b. F2 613 creates new mapping 
20 tables which are used to configure the bits of the leading byte 
of the sequence number field to represent the transport level 
information (protocol and port number) . This is done in a 
similar fashion to that described in the case illustrated in 
Fig. 5b. 

25 When a packet arrives at Fl 611 from SI 601, Fl 611 

examines the leading byte of the sequence number field and 
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based on the mapping tables that it received from SI 601, Fl 
611 determines the transport level information. Using mapping 
tables created by Fl 611, Fl 611 then inserts suitable values 
into the leading byte of the sequence number field of the outer 
5 ESP protocol header. At F2 613 , the outer ESP protocol header 
is removed, and the transport mode ESP protocol packet is what 
flows between F2 613 and D 605. 

The present invention as described above provides a 
mechanism by which transport level information can be conveyed 
10 to intermediate nodes in the presence of IPsec security 
2i protocols, particularly ESP protocol and AH protocol. The 

si transport level information of importance here are the 

fl transport protocol (TCP/UDP/ICMP) and the port number. The 

bi mechanism was discussed for transport mode, tunnel mode and 

ML 5 nested ESP protocol security processings. Using such 
fSJ mechanisms, intermediate nodes such as diff-serv 

£ 5 I 

*3 markers/classifiers, f irewalls/policers as well as network 

management nodes can perform their respective functions. These 
nodes require such transport level information for their 

2 0 functioning . 

While the present invention has been described in 
detail and pictorially in the accompanying drawings it is not 
limited to such details since many changes and modifications 
recognizable to those of ordinary skill in the art may be made 

2 5 to the invention without departing from the spirit and the 
scope thereof . 
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